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INTRODUCTION 


The  Naval  Postgraduate  School  Signal  Processing  and 
Display  Laboratory  III  is  used  for  research  and  education  in 
the  areas  of  operating  svstemsf  computer  graphics^  signal 
processing  and  hybrid  comouting.  The  laboratory's  eauipment 
configuration  is  illustrated  in  Fig.  1.  The  system  is  built 
around  two  Digital  Eauipment  Corooration  PDP-ll/50 
processors  that  share  some  memory/  some  peripherals/  and 
access  to  a  signal  processing  subsystem  consisting  of  a 
Computer  Signal  Processors  Incorporated  CSP  125  controller 
with  an  array  processor  and  an  analog  to  digital  converter. 
The  peripheral  suite  may  be  divided  into  two  major  groups; 
the  data  acquisition  group  and  the  display  group.  The 

A 

display  group  consists  of  dynamic  graphics  disolay  units 
that  are  designed  to  support  real-time^  interactive 
aoD 1 i c a t i ons .  The  data  acquisition  grouo  consists  of 
terminals^  diskSf  tapeSf  and  unit  record  equioment  that 
serve  the  dual  purposes  of  supoorting  a  healthy  environment 
for  program  development  and  providing  for  the  acquisition  of 
data  for  the  graphics  and  signal  processing  applications. 


Choosing  an  operating  system  for  the  laboratory 
presented  significant  challenges.  Traditional ly^  real-time 
operating  systems  have  orovided  poor  environments  for 
program  development.  The  operating  systems  that  are 


Q  £- 


"in 


Figure  1.  Equipment;  Configuration 


responsive  to  the  oemands  of  orogram  development  have 


provided  very  poor  real-time  and  interactive  environments. 
When  the  equipment  was  acquired#  no  single  PDP-11  operating 
system  met  all  the  needs  envisioned  for  the  laboratory.  It 
would  not  have  been  surprising  if  the  decision  had  been  made 
to  support  separate  operating  systems  tailored  to  the 

demands  of  the  two  areas.  Because  of  the  difficulties 

i 

inherent  in  maintaining  and  scheduling  multiple  operating 
systems  on  one  computer  system#  it  was  decided  to  attempt  to 
develop  a  unified  operating  system  having  specialized 
subsystems  to  support  both  foreground  real-time#  interactive 
processing  and  background  program  development  processing. 

The  baseline  operating  system  selected  was  UNIX#  a 
time-sharing  system  developed  at  Bell  Lapo ra t o r i es .  One  of 
the  important  advantages  of  UMIX  was  that  source  code  in  a 
high  level  language  was  furnished  with  the  system.  The 
availability  of  source  code  and  UNIX's  excel  lent  support  for 
program  development  promised  a  climate  favorable  to  the 
anticipated  system  modifications. 

The  UNIX  system  has  proved  to  be  a  good  selection. 
Several  projects  designed  to  augment  UNIX  are  in  progress  or 
have  been  completed.  One  area  of  particular  concern  has 
been  memory  manage m.ent.  Figure  1  reveals  that  the  several 
different  types  of  memory  in  the  configuration  present  some 
unusual  memory  management  problems;  but  the  figure  does  not 
reveal  the  complex  memory  management  problems  introduced  by 
the  real-time  applications#  especially  those  involving 
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direct  memory  access  by  display  devices.  Some  of  these 
oroblems  have  been  approached  in  earlier  work  12]  f  13]  f  im  . 
One  area  of  interest  that  had  not  been  investigated  prior  to 
this  thesis  was  the  applicability  of  advanced  memory 
management  techniques  to  the  laboratory  operating  system. 
This  area  was  particularly  attractive  because  the  PDP-11/50 
processors  have  a  Memory  Management  Unit  capable  of 
supporting  relocation^  paging,  and  some  segmentation."  The 
purpose  of  this  thesis  is  to  present  the  results  of  an 
investigation  into  the  suitability  of  segmentation  and 
paging  in  the  modified  UNIX  operating  evironment  at  the 
Naval  Postgraduate  School  Signal  Processing  and  Display 


Laboratory 


II 


THE  PDP-11/50 


A.  GENERAL  ARCHITECTURE 

The  PDP-11/50  [51  is  a  powerful/  medium  scale/  general 
purpose/  16 -bit  minicomputer.  It  is  well  designed  to 
suDport  multiprogramming  or  real-time  applications.  Its 
features  include  a  priority  interrupt  structure/  two  general 
purpose  register  sets/  and  three  processor  states  (Kernel/ 
Supervisor/  and  User).  Two  of  the  most  important  aspects  of 
the  PDP-11  architecture  are  its  inout/output  scheme  and  its 
dependence  on  processor  stacks.  Both  of  these  have 
important  impacts  on  the  memory  management  methods 
considered  in  this  thesis. 

The  most  important  component  of  the  PDP-11  input/outout 
scheme  is  the  UNIBUS,  The  UNIBUS  is  a  high  speed/ 
bidirectional/  asynchronous  bus  that  connects  the  CPU/ 
peripherals/  and  memory.  Devices  attach  to  the  UNIBUS  with 
hardware  control  and  data  registers  that  have  simulated 
locations  assigned  in  the  uppermost  ^/ORb  words  of  the 
address  space.  This  simplifies  the  programming  of 
peripheral  devices  because  no  special  class  of  inout/outout 
instructions  is  required.  Data  and  control  information  is 
entered  into  or  retrieved  from  the  devices'  registers  as  if 
they  were  actual  memory  locations.  The  UNIBUS  can  be 
controlled  either  by  the  CPU  or  by  a  peripheral  device. 


This  makes  it  possible  for  the  devices  to  access  main  memory 
with  almost  no  processor  intervention.  The  arbitration  unit 
that  assigns  control  of  the  UNIBUS  to  a  reauesting  device  or 
CPU  gives  maximum  priority  to  a  direct  memory  access  request 
from  a  peripheral  device.  Because  the  POP-11/50  does  not 
feature  a  lock  and  key  memory  protection  scheme^  the 
protection  of  the  operating  system  from  DMA  devices  is  a 
significant  memory  management  problem. 


A  PDP-11  stack  is  an  area  of  memory  set  aside  under 
program  control  for  temporary  storage^  subroutine  linkage^ 
and  interrupt  service  linkage.  In  concept#  it  is  a  classic 
"last-in#  first-out"  stack  of  the  type  described  in  ref. 
[61.  Each  processor  state  has  a  register  specifically 
designed  to  be  its  processor  stack  pointer.  The  intructions 
that  are  provided  for  standard  PDP-11  routine  linkage  and 
interrupt  handling  "push"  and  "poo"  parameters#  linkage 
information#  and  status  information#  using  the  current 
processor  stack.  Other  instructions  are  provided  to 
facilitate  stack  manipulation.  Properly  used#  stacks 
provide  automatic  nesting  of  subroutines#  reentrancy#  and 
recursion.  They  also  help  to  decrease  the  overhead  that  is 
inherent  in  linkage  and  interrupt  processing.  The  only 
major  disadvantage  of  using  stacks  is  that  prooerly 
controlling  dynamically  growing  and  shrinking  stacks  is  a 
significant  memory  management  problem. 
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B.  memory  management  features 


1 .  Cone  eo  t  s 

Even  though  the  POP-11/50  comouter  has  a  16-bit  word 
lengths  its  basic  addressing  logic  uses  an  18-bit  direct 
byte  physical  address.  In  the  PDP-11/50  system’s  simplest 
configuration,  the  two  most  significant  bits  of  the  18-bit 
address  are  not  imolemented.  The  address  space  is  limited  to 
32K  words  (32  *  1,024  words).  The  address  space  is  used  to 
reference  up  to  28K  words  of  main  memory  and  the  4K  words  of 
UNIBUS  device  registers.  To  expand  main  memory  beyond  28K 
bytes,  the  PDP-11  Memory  Management  Unit  (MMU)  must  be  added 
to  the  configuration.  This  unit  interprets  16-bit  addresses 
as  virtual  addresses  from  which  it  constructs  18-bit 
physical  addresses.  Up  to  124K  words  of  main  memory  can  be 
made  addressable  with  the  MMU. 

2.  Address  Formation 

With  the  MMU  installed,  the  PDP-11/50  supports  two 
32K  word  virtual  address  spaces  for  each  of  its  three 
processor  states.  Each  state  has  an  Instruction  Space  (I- 
space)  and  a  Data  Space  (D-space).  Instruction  fetches, 
index  words,  absolute  addresses,  and  immediate  operands 
reference  I-space.  All  other  references  are  to  D-space. 
The  MMU  constructs  physical  addresses  using  the  information 
in  six  sets  of  relocation  and  descriptor  registers.  The  set 
used  depends  on  the  orocessor  mode  and  the  type  of  address 
reference.  These  registers  and  MMU  control  registers  are 
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assigned  simulated  memory  locations  and  may  be  accessed  in 
the  same  way  as  UNIBUS  device  registers.  Each  register  set 
consists  of  eight  Page  Address  Registers  (PARs)  and  eight 
Page  Descriptor  Registers  (PDRs).  Address  formation  is 
shown  in  Fig.  2.  The  MMU  subdivides  each  16-bit  virtual 
address  into  three  fields:  the  displacement  in  block  (DIB)/ 
bits  0  to  5;  the  block  number  (BN),  bits  6  to  12;  and  the 
active  page  field  (APF),  bits  13  to  15.  The  APF  is  used  to 
select  a  PAR,  The  twelve  low  order  bits,  or  page  address 
field  (RAF)/  of  the  PAR  are  added  to  the  BN  to  form  a  12-bit 
physical  page  block  number  (PBN).  The  DIB  is  concatenated 
with  the  PBN  to  form  the  18-bit  physical  address.  There  are 
two  very  important  implications  of  this  scheme:  the  basic 
granularity  of  the  memory  is  the  b^-byte  block  and  a  page 
may  begin  on  any  block  boundary  in  the  memory.  The  concept 
of  the  page  frame  is  not  applicable  to  the  PDP-11. 

3.  Access  Control 

The  PORs  are  used  to  control  access  to  pages,  to 
specify  their  lengths,  and  to  provide  memory  management 
data.  The  format  of  a  POR  is  shown  below. 
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Figure  3.  POR  Format 


The  fields  in  the  PDR  are:  the  access  control  field  (ACF), 
bits  0  to  2;  the  expansion  direction  bit  (ED),  bit  3;  the 
written  bit  (W),  bit  6;  the  accessed  bit  (A),  bit  7;  and  the 
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Virtual  Address 


1S 


Figure  2.  Physical  Address  Formation 


page  length  field  (PLF),  bits  8  to  1^.  Among  access  options 
that  may  be  specified  in  the  ACF  are!  read  only/  abort  on 
write/  read/write/  no  aborts;  and  non-resident/  abort  all 
accesses.  Because  a  page  need  not  be  a  full  128  blocks  in 
length/  the  PLF  and  the  ED  bits  are  used  to  validate  the 
virtual  0N  before  memory  access  is  permitted.  If  the  EO  bit 
is  not  set/  the  PLF  is  the  page  length  in  blocks  minus  one. 
In  this  case/  any  attemot  to  access  this  page  with  a  3N 
greater  than  the  PLF  is  aborte'd.  The  ED  bit  is  to  be  set 
when  the  page  contains  a  stack  extending  downward  from  the 
upper  end  of  the  page's  address  range.  If  the  EO  bit  is 
set/  the  PLF  is  128  minus  the  page  lenath  in  blocks.  In 
this  case/  any  attempt  to  access  this  page  with  a  BN  less 
than  the  PLF  is  aborted. 

The  MMU  provides  a  mechanism  by  which  a  Kernel  mode 
suoervisory  routine  may  be  invoked  when  a  memory  management 
abort  occurs.  Enough  information  is  preserved  in  MMU  status 
registers  to  describe  the  tyoe  of  abort  and  to  identify  the 
offending  instruction  and  address.  This  feature  could  be 
used  in  a  demand  caged  memory  manager/  for  example/  to 
resolve  page  faults. 

The  W  and  A  bits  provide  page  reference  data  for  the 
memory  management  software.  The  W  bit  is  set  if  the  page 
has  been  modified  since  the  PDR  was  loaded.  The  A  bit  is 
set  if  the  page  has  been  accessed  since  the  PDR  was  loaded. 
Both  bits  are  reset  whenever  the  PDR  is  modified. 
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THE  UNIX  TIME-SHARING  SYSTEM 


A.  CONCEPTS 

UNIX  [7]  is  a  terminal  oriented/  interactive/  time- 
sharinq/  operating  system  developed  at  Bell  Laboratories  for 
use  on  the  PDP-11  family  of  minicomputers.  Most  of  UNIX  is 
written  in  "C/"  C8]  a  high  level  language  also  developed  by 
Bell  Laboratories.  A  small  part  of  UNIX  is  written  in  "as/” 
[9]  a  Bell  Laboratories  variant  of  the  PDP-11  assembler 
language.  Among  the  most  significant  of  UNIX's  features 
are:  a  hierarchical  file  system/  a  device  independent 
input/output  scheme/  and  multi-tasking. 

The  basic  unit  of  work  under  UNIX  is  the  process.  Each 
process  is  an  execution  of  a  program  file  from  the  UNIX  file 
system.  When  UNIX  "bootstraps"  itself  into  memory  at  system 
initiation  time/  it  "handcrafts"  the  first  two  processes: 
process  0  and  process  1.  Process  0/  which  may  be  thought  of 
as  an  execution  of  UNIX/  is  the  master  control  process. 
Process  1  sets  up  the  system?  all  subseouent  processes  are 
descendents  of  process  1. 

All  processes  except  process  0  execute  in  User  processor 
state.  If  a  process  reouires  service  from  UNIX/  it 
communicates  its  request  bv  means  of  a  system  call.  System 
calls  are  mechanized  by  use  of  TRAP  instructions  which 
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interrupt  the  processor/  change  the  processor  state  to 
Kernel/  and  cause  the  approriate  service  routine  to  be 
executed.  When  the  system  call  completes/  it  returns  to  the 
calling  process  with  the  processor  in  User  state. 

A  process  creates  descendents  by  use  of  the  "fork" 
system  call.  This  system  call  creates  an  exact  duplicate  of 
the  calling  process.  The  new  process  is  referred  to  as  a 
child  process  and  the  original  process  is  referred  to  as  a 
parent  process.  The  parent  may  continue  to  execute/  perhaps 
creating  more  children/  or  it  may  use  the  "wait"  system  call 
to  suspend  execution  until  its  child  has  completed 
execution.  The  child  may  continue  to  execute  the  same 
program  as  its  parent  or  it  may  invoke  a  new  program  py  use 
of  the  "exec"  system  call.  A  child  may  also  create  children 
of  its  own.  When  a  child  completes  processing/  it 
terminates  by  means  of  the  "exit"  system  call.  Among  other 
actions/  "exit"  notifies  the  parent  of  the  child's  demise. 

Process  1  begins  its  role  as  grandsire  by  creating  one 
child  for  each  terminal  in  the  system.  Each  child  opens  its 
assigned  terminal/  sends  a  message  reauesting  a  user  to  log 
in/  and  awaits  a  reply.  When  a  user  successfully  completes 
the  log  in  procedure/  the  child  invokes  a  new  program  called 
the  Shell.  The  Shell  interprets  commands  specified  by  the 
user  and  creates  children  which  invoke  other  programs  to 
carry  out  the  user's  commands.  When  the  user  logs  off/  his 
teminal's  Shell  process  terminates.  Process  1/  which  has 
been  patiently  waiting  for  this  to  happen/  is  notified  and 
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it  creates  a  new  child  for  the  terminal.  The  new  child 
reopens  the  terminal  and  sends  another  log  in  request, 

B.  MEMORY  management 

In  conceot/  the  UNIX  memory  manager  is  a  relocatable 
partitioned  memory  manager  [10]  with  swapping  and  limited 
segmentation.  Each  process  has  an  image  that  must  reside  in 
a  contiguous  partition  while  the  orocessor  is  executing  on 
behalf  of  the  orocess.  The  image  remains  in  memory  during 
the  execution  of  other  processes  unless  it  must  be  written 
out  (swapped  out)  to  a  direct  access  device  to  satisfy  the 
memory  requirements  of  a  higher  priority  process. 
Relocation  and  storage  protection  are  accomplished  with  the 
MMU,  When  the  orocessor  is  executing  on  behalf  of  a 
process#  the  memory  management  registers  are  loaded  so  that 
the  process  can  access  only  its  own  image  and#  if 
applicable#  a  text  segment  shared  with  other  processes. 
Because  a  orocess  executes  in  User  mode#  its  adaress  space 
is  the  User  address  space#  however#  a  part  of  the  process's 
image  called  the  UVECTOR  is  established  in  Kernel  D-space. 
The  UVECTOR  contains  process  status  information  needed  by 
UNIX  and  the  Kernel  mode  processor  stack  to  be  used  while 
the  process  is  active.  Not  all  process  control  information 
is  located  in  the  UVECTOR.  Information  that  must  remain 
addressable  even  when  the  orocess  is  not  executing  remains 
resident  for  the  life  of  the  orocess  in  Kernel  D-soace  in  a 
control  block  called  a  PROC.  If  the  process  shares  its  text 
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with  other  processes^  its  PROC  contains  a  pointer  to  yet 
another  control  block  resident  in  Kernel  0-space.  This 
control  block  is  called  the  TEXT.  It  contains  information 
that  UNIX  uses  to  control  the  sharing  of  the  text  segment. 
APPENDIX  A  contains  detailed  information  on  the  UVECTOR, 
PROC,  and  TEXT. 

A  orocess's  image  is  created  when  "fork"  copies  its 
parent's  image.  Whenever  a  process  uses  "exec"  to  invoke  a 
new  program,  the  process's  image  is  recreated  according  to 
specifications  in  the  program  file  to  be  executed.  A 
process's  image  differs  depending  on  whether  or  not  it 
shares  text.  The  image  of  a  text  sharing  orocess  consists 
of  its  UVECTOR,  data,  and  User  mode  processor  stack.  The 
shared  text  is  established  in  memory  independently  of  the 
images  of  the  processes  sharing  it.  In  the  image  of  a  non¬ 
sharing  process,  the  text  is  lumped  together  with,  and 
considered  to  be  part  of,  the  data.  If  the  process  shares 
text,  "exec"  checks  to  see  if  a  cooy  of  the  text  is 
available  in  the  system.  If  it  is  not,  "exec"  establishes  a 
cooy , 


The  User  address  soace  of  a  text  sharing  process  may  be 
established  in  two  different  ways:  seoaratea  instruction  and 
data  spaces  or  combined  instruction  and  data  soaces.  The 
User  address  soace  of  a  non-sharing  process  may  only  be 
established  with  combined  instruction  and  data  soaces.  If  a 
process's  address  spaces  are  combined,  its  I-space  and  D- 
space  are  identical,  A  separation  flag,  determined  by 
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**exec^’  from  the  file  tyoe  and  kept  in  the  process’s  UVECTOR/ 

controls  the  method  used  to  establish  the  address  space  of  a 

text  sharing  process.  If  a  process’s  address  soaces  are 

separated/  its  shared  text  segment  is  addressable  beginning 

at  User  I-space  address  0  and  its  data  is  addressable 

beginning  at  User  D-space  address  0.  If  a  combined  process 

has  shared  text/  its  shared  text  segment  is  addressable 

\ 

beginning  at  address  0  in  both  User  I-space  and  User  0- 
space;  and  its  data  is  addressable  beginning  at  the  first 
word  boundary  (page  boundary)  beyond  the  end  of  the  text  in 
both  User  I-space  and  User  D-space.  If  a  combined  process 
does  not  have  shared  text/  its  text  is  addressable  beginning 
at  address  0  in  both  User  I-space  and  User  O-space)  and  its 
data  is  addressable  beginning  at  the  first  word  boundary 
beyond  the  end  of  the  text  in  both  User  I-soace  and  User  D- 
space.  A  process's  stack  is  addressable  extending  downward 
from  the  highest  address  in  User  0-soace  or  in  I-space  ano 
D-space.  The  access  control  specified  in  the  PDRs  of  shared 
text  pages  is  read  only.  All  other  pages/  including  non- 
shared  text/  are  read-write  access. 

There  are  two  system  calls  that  a  process  may  use  to 
change  the  size  of  its  image  without  invoking  a  new  program. 
These  system  calls  are  "brk"  and  "sbrk"  (111.  These  are 
used  to  increase  or  decrease  the  size  of  the  process's  data 
area.  They  are  used  mainly  in  programs  with  storage 
requirements  that  have  great  variations  depending  on  input. 
The  size  of  a  process's  image  may  increase  in  another  way. 
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If  its  User  mode  processor  stack  grows  beyond  the  space 
initially  allocated  to  it/  UNIX  dynamically  increases  the 
amount  of  memory  provided, 

C.  INPUT  OUTPUT  SYSTEM 

1,  Standard  Input/Output 

The  UNIX  standard  input/outout  (I/O)  system  (12]  is 
designed  to  separate  the  user  from  device  dependencies/  to 
keep  control  blocks  out  of  the  User  address  space/  and  to 
preserve  process  re  1 oc at ab i 1 i t y .  Two  classes  of  devices  are 
supported  under  the  standard  I/O  system:  character-devices 
and  block-devices.  Character-devices  are  read  and  written 
one  byte  at  a  time  using  a  UNIBUS  device  register  as  an  I/O 
port,  B 1 oc k -de V i c es  are  read  and  written  in  512  byte  blocks 
using  direct  memory  access  (DMA).  UNIX  provides  the 
expected  system  calls  to  create/  open/  access/  and  close 
files  on  both  device  types.  It  also  provides  buffer  areas 
in  Kernel  D-soace  for  character-device  I/O  queues  and  for  a 
pool  of  block  device  buffers. 

When  a  process  requests  a  write  to  a  character- 
device/  an  I/O  support  routine  (device  driver  routine)  moves 
the  data  to  the  device's  output  queue  or  directly  to  the 
device.  When  a  process  requests  a  character-device  read/ 
the  device  driver  receives  the  data  from  the  device  and 
moves  it  to  the  User  address  space. 
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When  a  block  write  is  requested/  the  device  driver 


acquires  a  buffer  from  the  pool  in  Kernel  D-space/  moves  the 
data  from  the  User  adaress  space  to  the  buffer/  and  Places 
the  buffer  on  the  device's  output  queue.  when  a  block  read 
is  requested/  the  driver  places  the  request  in  the  device's 
input  queue/  and  acquires  a  buffer  to  which  the  device  will 
transfer  the  data  when  the  request  is  honored.  After  the 
device  has  transferred  the  data  to  the  buffer/  the  driver 
moves  the  data  to  the  User  address  soace. 

The  significance  of  standard  I/O  from  the  memory 
management  point  of  view  is  the  way  in  which  it  localizes 
DMA  accesses  to  Kernel  D-scace.  This  is  imoortant  because  a 
DMA  device  must  be  given  the  Physical  address  of  the  area 
from  which  or  to  which  the  data  will  be  transferred.  In 
Kernel  0-space/  virtual  and  Physical  addresses  are 
identical.  All  addresses  used  to  move  data  between  the  User 
address  space  and  the  Kernel  D-space  are  virtual/  no  device 
or  routine  needs  to  know  the  physical  address  of  the 
requesting  process's  I/O  area.  This  means  that  standard  I/O 
is  completely  compatible  with  dynamic  relocation  of  the 
requesting  process. 

2.  Raw  Block-device  Input/Output 

Raw  block-device  I/O  [12J  is  a  scheme  whereby  I/O 
takes  place  directly  between  the  requesting  process's  memory 
and  the  device.  The  advantages  of  this  type  I/O  are  that  it 
allows  the  use  of  blocks  larger  than  512  bytes  and  that  it 
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avoids  the  overhead  of  moving  the  data  between  the  User 


address  space  and  the  Kernel  D-space.  Although  it  might 
seem  that  the  data  moving  overhead  would  be  smalls  this  is 
not  the  case  because  the  POP-11  lacks  a  block-move 
instruction.  The  only  way  to  move  a  group  of  data  words  is 
with  a  program  loop.  This  means  that  several  instructions 
must  be 'fetched  and  executed  to  move  each  word  of  data  or» 
in  some  cases^  to  move  each  byte  of  data.  The  major 
disadvantage  of  this  type  of  I/O  is  that  the  block-device 
must  be  given  the  physical  address  of  the  input  or  output 
area  in  the  User  address  space?  thus>  the  reguesting  process 
must  be  "locked"  in  memory  during  the  I/O  operation.  This 
prevents  the  memory  manager  and  process  controller  from 
making  optimum  use  of  system  resources. 

In  practicef  raw  I/O  does  not  have  an  imoortant 
effect  on  operating  system  performance  because  it  is  very 
rarely  used.  It  is  important  because  future  aoplications 
will  use  it  and  because  supporting  it  presents  some 
difficult  memory  management  problems. 
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IV.  MEMORY  MANAGER  DESIGN 


A.  SEGMENTATION 

The  fundamental  oroblem  addressed  in  this  thesis  is  a 
pragmatic  one:  how  best  to  modify  the  UNIX  memory  manager  in 
order  to  make  more  complete  use  of  the  capabilities  of  the 
available  memory  management  hardware.  Shared  text  is 
already  well  segmented  in  UNIX,  so  the  first  step  taken  was 
determining  a  good  method  of  dividing  the  process  image  into 
segments.  The  important  considerations  were  that  the 
segments  be  logically  seoarate  and  i noependen t 1 y  managable 
in  main  memory.  It  proved  to  be  possible  and  desirable  to 
use  the  natural  division  already  discussed:  UVECTOR,  data 
(including  non-shared  text),  and  the  User  processor  stack. 
This  division  has  the  apoeal  of  being  straightforward  and  of 
being  an  efficient  wav  of  cooing  with  the  problem  of 
managing  the  dynamic  size  changes  of  the  data  and  stack 
areas  . 

A  study  of  the  UNIX  system  showed  that  reestablishing 
the  process  image  when  the  data  or  stack  changes  size  is  a 
major  source  of  memory  management  overhead.  Whenever  either 
the  stack  or  the  data  changes  size,  the  UNIX  memory  manager 
has  to  acquire  memory  for  an  entire  new  image  and  copy  the 
UVECTOR,  data,  and  stack  to  it.  The  cost  of  this  copying  is 
about  10  m i c ro“seconds  of  processor  time  oer  word  if  memory 
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is  available  for  the  new  image» 


and  several  seconds  of 


elapsed  time  if  memory  has  to  be  acquired  by  swapping  other 
processes  out  of  memory.  If  changing  size  were  an 
infrequent  occurrence^  this  cost  would  not  Pe  excessive  but 
studies  have  shown  that  some  of  the  most  commonly  used 
orograms  change  size  often.  Among  these  programs  are:  "cc/” 
the  "C"  language  compiler;  "ed/"  the  text  editor;  and  "as»" 
the  assembler.  With  the  data  and  stack  in  '  seoarate 
segments^  overhead  is  reduced  because  only  the  segment  that 
changes  size  has  to  be  copied.  If  the  segments  were  divided 
into  pages/  only  the  last  page  of  the  segment  would  have  to 
be  copied/  reducing  overhead  even  more. 

There  is  another  imoortant  reason  for  establishing 
separate  segments  for  the  data  and  the  stack.  Several 
applications  (11  planned  for  the  Signal  Processing  and 
Display  Laboratory  will  require  a  memory  manager  that  can 
place  a  process's  data  segment  in  a  specific  area  of  main 
storage.  Specific  placement  will  be  required  to  reduce  the 
overhead  of  processor  to  processor  and  processor  to  device 
communication  and  to  protect  processes  from  aestruction  by 
errant  operations  by  DMA  devices.  An  example  is  a  process 
that  requires  the  CSP  125  array  processor.  The  CSP  125  can 
access  only  a  Portion  of  the  memory  available  in  the 
laboratory  system.  Any  orocess  that  communicates  with  the 
CSP  125  must/  therefore/  have  its  data  segment  placed  within 
the  memory  that  the  CSP  125  can  access. 
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Another  examole  is  a  real-time  graphics  orocess  using 
the  Vector  General  3D3I  display  unit.  This  DMA  device 
retrieves  and  interprets  its  display  list  forty  times  per 
second.  Instructions  in  the  display  list  can  cause  the 
device  to  store  data  anywhere  within  the  32K  word  memory 
segment  containing  the  list.  To  protect  the  UVECTOR  and 
stack  of  the  process  using  this  device#  the  display  list 
must  be  isolated  in  a  32K  word  memory  segment. 

B.  ALLOCATION  OF  MEMORY 


After 

the 

method 

of  segmentation  was 

aec i ded 

spec i f i cs 

0  f 

the 

memory  allocation 

techni gue 

considered.  It  was  assumed  at  first  that  a  paged  segmented 
memory  manager  [13]  would  be  the  best  choice.  After  careful 
consideration#  a  partitioned  segmented  memory  manager  was 
chosen.  Partitioned  segmentation  is  a  variant  of  paged 
segmentation  first  suggested  by  Randall  (1^1]  based  on 
simulation  studies  of  simple  segmentation  and  paged 
segmentation.  The  differences  between  paged  and  partitioned 
segmentation  are:  the  basic  Quantum  of  storage  allocated  and 
the  method  of  physical  address  formation  reguired. 

The  allocation  Quantum  in  paged  segmentation  is  the  page 
frame#  an  area  of  memory  large  enough  to  hold  exactly  one 
virtual  page.  Each  reQuest  for  storage  is  the  same  size 
(page  size)  and  each  free  area  is  an  integral  multiple  of 
this  size.  This  strategy  reduces  the  loss  of  storage  due  to 
external  fragmentation  because  no  area  of  free  storage  is 
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ever  too  small  to  satisfy  a  request  for  a  page  of  memory. 
It  also  simolifies  the  memory  allocation  and  deallocation 
primitives  because  they  need  to  respond  to  memory  requests 
of  only  one  size.  The  disadvantage  of  paged  allocation  is 
that  even  a  partial  virtual  page  is  allocated  a  full  page 
frame.  The  unused  memory  in  cage  frames  allocated  to 
partial  pages  causes  a  loss  of  usable  storage  called 
internal  fragmentation. 

The  basic  idea  behind  partitioned  segmented  allocation 

is  the  reduction  of  internal  fragmentation.  A  partitioned 

segmented  memory  manager  allocates  storage  in  a  quantum  that 

is  smaller  thanr  but  an  integral  divisor  off  the  page  size. 

The  largest  contiguous  area  allocated  is  eaual  to  the  page 

size?  butf  when  memory  is  allocated  for  a  partial  oage^  only 

0 

the  smallest  number  of  quanta  larger  than  the  size  is 
allocated.  Internal  fragmentation  still  occurs  but  the 
average  loss  per  partial  page  is  only  half  a  quantum  rather 
than  half  a  page  frame.  There  are  two  disadvantages  of 
partitioned  segmentation:  the  memory  manager  must  be  more 
complex  because  it  must  respond  to  reauests  for  a  number  of 
different  memory  sizes;  and  external  fragmentation  will 
occur  . 

Physical  address  formation  in  a  paged  segmented  system 
is  simple  because  pages  reside  in  memory  at  physical 
addresses  that  are  integral  multiples  of  the  page  size. 
Because  the  page  size  is  always  chosen  as  a  power  of  two/ 
the  physical  address  is  formed  from  the  virtual  address  by 
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concatenating  the  virtual  address’s  d  i  so  1  ac  emen  t i  n-page 
with  the  physical  page  frame  number.  In  a  partitioned 
segmented  system,  pages  are  placed  in  memory  at  physical 
addresses  that  are  integral  multiples  of  the  quantum  of 
allocation.  Because  the  quantum  of  allocation  is  chosen  as 
a  power  of  two/  the  physical  address  is  formed  by  adding  the 
physical  page  quantum  number  to  the  virtual  address’s 
quan t um-w i t h i n -page  and  then  concatenating  the  virtual 
address’s  displacement-within-quantum  with  the  result. 

Because  the  PDP-ll/50  MMlj  can  support  either  a  paged  or 
partitioned  segmented  memory  manager,  the  important 
consideration  in  deciding  between  the  two  memory  managers 
was:  how  the  loss  of  storage  utilization  caused  by  external 
fragmentation  with  a  partitioned  segmented  memory  manager 
would  compare  to  the  loss  of  storage  utilization  caused  by 
internal  fragmentation  with  a  paged  segmented  memory 
manager.  A  definitive  answer  to  this  question  is  not 
possible  unless  both  memory  managers  are  tested;  however,  it 
is  easy  to  show  that  the  storage  losses  with  a  paged 
segmented  memory  manager  would  be  unacceptaole  in  the  UNIX 
environment.  The  argument  for  this  premise  is  based  on  the 
very  large  C^K  word)  page  size  imposed  by  the  memory 
management  hardware,  the  extremely  small  number  of  page 
frames  available,  and  the  small  segment  sizes  that  result 
when  the  orocess  image  is  divided  into  ^three  segments.  The 
most  important  consideration  is  the  comparison  between 
segment  size  and  page  size.  If  the  segments  were  very  large 
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compared  to  the  pages#  the  percentage  of  partial  pages  would 
be  small  and  the  resulting  loss  of  utilization 
insignificant.  If  the  segments  were  small  compared  to  the 
pages#  almost  all  pages  would  be  partial  pages  and  the 
resulting  loss  of  utilization  would  be  high. 

The  UVECTOR  segment  is  fixed  in  length  at  .5K  words. 
The  initial  stack  segment  allocation  for  all  processes  is 
.b^K  words.  Stacks  grow  dynamically#  but  observations  have 
shown  that  this  is  a  rare  occurrence.  Estimates  of  the 
average  sizes  of  the  text  and  data  segments  were  determined 
by  examining  the  program  files  of  70  freguently  used 
programs.  The  mean  text  segment  size  was  determined  to  be 
1.9K  words  and  the  mean  data  segment  size  at  the  start  of 
execution  was  determined  to  be  2.2K.  Data  segments 
frequently  grow  but  the  largest  increase  that  has  been 
observed  is  about  .5K  words  for  one  phase  of  the  "C" 
compiler.  Even  making  the  generous  assumption  that  average 
combined  data  and  stack  growth  is  .5K#  these  figures  show 
that  the  paged  segmented  memory  manager  would  waste  more 
memory  than  it  used  productively.  It  would  allocate  four 
pages  (16K  words)  for  the  average  shared  text  process  of 
which  an  average  of  5.7K  words  would  be  used. 

The  segment  size  data  is  comoletely  counter  to 
experience  gained  in  large  scale  comouter  systems.  It  was 
completely  unexpecteo.  Because  the  mean  segment  sizes 
observed  were  all  less  than  a  page#  doubts  were  raised  about 
the  desirability  of  selecting  any  memory  management 
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technique  more  comolicated  than  simple  segmentation.  In 
spite  of  the  doubts^  it  was  decided  to  continue  with 
development  of  a  UNIX  with  a  partitioned  segmented  memory 
manager  (PSUNIX).  It  was  believed  that  this  effort  would 
best  serve  to  explore  all  memory  management  options.  Design 
work  was  started^  however^  on  a  version  of  UNIX  with  a 
simple  segmented  memory  manager  (SUNIX).  SUNIX  was  to  be  a 
fall-back  position  if  the  performance  of  PSUNIX  proved  to  be 
unsat i sfactory. 

When  the  partitioned  segmented  memory  manager  was 
chosen^  the  only  remaining  design  Question  was  the  size  of 
the  quantum  of  allocation.  The  b^-byte  block,  the  smallest 
quantum  supported  by  the  memory  management  hardware,  was 
selected.  This  choice  was  based  on  the  practical 
consideration  that  it  required  no  change  to  the  existing 
UNIX  memory  allocation  and  deallocation  primitives. 
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V 


VOOIFICATIONS  TO  UNIX 


A.  OVERVIEW  AND  PHILOSPHY 

Modifying  the  UNIX  memory  manager  to  oroduce  PSUNIX  was 
a  formidable  task  that  required  writing  aoproximately  500 
lines  of  new  code  and  comprehending  and  modifying  existing 

I 

programs  totaling  more  than  1^800  lines  of  code.  The 
approach  that  was  taken  to  this  oroblem  was  to  avoid  putting 
large  sections  of  new  code  into  existing  orograms.  The  new 
code  that  was  needed  to  support  the  memory  manager  was 
centralized  in  several  small  self-contained  functions 
(primitives).  Wherever  possible^  changes  to  existing 
routines  were  limited  to  removing  calls  to  the  old  memory 
management  primitives  and  replacing  them  with  calls  to  the 
new  memory  management  primitives.  The  goals  of  this 
approach  were  to  make  the  the  general  structure  of  memory 
management  in  PSUNiX  seem  familiar  to  those  who  understood 
the  UNIX  structure  and  to  simplify  debugging  by  localizing 
new  code.  These  goals  were  realized. 

The  changes  made  to  implement  PSUNIX  can  be  divided  into 
five  areas: 

1.  Control  Block  Modifications 

2.  Memory  Management  Support  Modifications 

3.  Swap  Space  Allocation  Modifications 
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4.  Raw  I/O  Support  I'^od i  f  i  c a t  i  on s 


5.  Support  Program  i^od i  f  i  c a t  i  on s 

Each  of  these  areas  is  described  in  a  subsequent  section  of 
this  chapter.  Supporting  documentation  can  be  found  in  the 
appendices.  APPENDIX  A  contains  detailed  information  on 
control  blocks  related  to  memory  management.  APPENDIX  B 
contains  detailed  documentation  of  memory  management 
routines  found  in  UNIX,  PSUNIX,  and  the  proposed  simple 
segmented  version,  SUN IX. 

B.  CONTROL  BLOCK  MODIFICATIONS 

The  only  control  blocks  modified  were  the  PROC  (process 
control)  and  the  TEXT  (shared  text  segment  control).  No  new 
control  blocks  were  added  except  page  tables  which  are 
allocated  in  temporary  storage  and  used  as  work  space  during 
memory  allocation  and  deallocation.  In  UNIX,  the  PROC 
contains  the  size  and  address  of  the  image.  In  PSUNIX,  the 
PROC  was  expanded  so  that  it  could  fulfill  the  same  role  as 
the  MULTICS  (151  Segment  Map  Table.  The  image  size  and 
address  were  removed  and  the  segment  sizes  and  cage 
addresses  were  added.  In  both  versions  of  the  operating 
system,  the  TEXT  performs  the  same  function  as  an  entry  in 
the  MULTICS  Active  Segment  Table.  The  only  modification 
required  for  PSUNIX  was  the  addition  of  a  page  address 
array.  APPENDIX  A  provides  detailed  information  on  the 
PROC,  TEXT,  and  several  other  control  clocks  that  are 
important  to  memory  management. 
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C.  MEMORY  MANAGEMENT  SUPPORT  MODIFICATIONS 

The  basic  form  of  the  memory  management  modifications 
has  been  presented  in  the  previous  chapter.  APPENDIX  8 
provides  complete  documentation  of  the  new  memory  management 
primitives  under  the  heading  "page.c."  It  also  provides 
documentation  of  the  changes  made  to  existing  UNIX  programs 
that  call  these  primitives.  Functions  of  particular 
interest  are:  "newprocf"  which  creates  a  process's  image  by 
copying  the  image  of  the  process's  parent;  "exec/"  which 
recreates  a  process's  image  when  the  process  invokes  a  new 
program;  "xalloc#"  which  establishes  shared  text  segments; 
"expand/"  which  changes  a  process's  image  size;  "scheo/" 
which  swaps  processes  into  and  out  of  mempry;  "xfree/"  which 
removes  shared  text  segments  from  the  system;  and  "exit/" 
which  terminates  processes  and  frees  their  resources. 

D.  SWAP  SPACE  ALLOCATION  MODIFICATIONS 

The  UNIX  method  of  controlling  swap  space  is  to  allocate 
it  to  a  process  when  the  process  is  to  be  swapped  out  and  to 
free  it  as  soon  as  the  process  returns  to  memory.  The 
advantage  of  this  is  that  it  keeps  the  demand  for  swap  space 
at  a  minimum  but  the  disadvantage  is  that  it  reauires  an 
allocation  and  a  deallocation  whenever  a  process  is  swapped. 
UNIX  swap  I/O  is  extremely  efficient  because  the  process 
image  is  contiguous  in  memory.  This  allows  UNIX  to  swap  a 
process  with  one  I/O  operation. 
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The  PSUNIX  methoa  of  controHinq  swap  soace  is  to 
allocate  it  to  a  process  the  first  time  the  process  is 
swapped  out  and  to  allow  the  process  to  keep  the  swap  space 
when  it  returns  to  memory.  A  process  loses  its  swap  space 
when  it  terminates  or  when  one  of  its  segments  becomes  too 
large  for  the  space  that  was  allocated.  In  both  versions  of 
the  operating  system/  the  process  is  allocated  a  contiguous 
area  of  swap  space.  This  reduces  the  allocation  overhead. 
PSUNIX  incurs  the  overhead  of  one  I/O  operation  per  page  in 
the  process's  image.  This  means  that  PSUIMIX  has  between 
three  and  four  times  as  much  swap  I/O  overhead  as  UNIX  for 
the  average  process. 

The  programs  concerned  with  swapping  are  documented  in 
APPENDIX  B.  Functions  of  particular  interest  are:  "xswap/” 
which  swaps  processes  out  of  memory?  "swap/"  the  swap  I/O 
call?  "pswap/"  a  PSUNIX  function  that  swaps  several  Pages  to 
or  from  memory?  and  "prswao/"  a  PSUNIX  function  that  returns 
a  swapped  process  to  memory. 

E.  RAW  I/O  SUPPORT  MODIFICATION 

As  has  been  described  previously/  raw  I/O  reauires  a  DMA 
transfer  directly  from  or  directly  to  a  process's  address 
space.  The  data  is  transferred  to  or  from  a  contiguous  area 
of  main  memory.  In  PSUNIX  this  presents  a  serious  problem 
if  the  data  area  spans  a  page  boundary  because  the  pages 
will  probably  not  be  contiguous.  The  only  efficient 
solution  to  this  problem  is  to  make  the  pages  contiguous. 
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The  function  "Dhysio/"  which  sets  up  raw  I/O  transfers^ 
was  modified  to  determine  if  each  transfer  spans  a  page 
boundary.  When  a  boundary  spanning  transfer  is  requested/ 
"physio"  calls  "contig/"  a  memory  management  primitive/  that 
reallocates  the  data  and  stack  segments  of  the  requesting 
process  so  that  both  of  them  are  allocated  contiguous 
memory.  The  process  is  also  flagged  as  one  that  requires 
contiguous  allocation.  Whenever  memory  is  allocated  for  the 
process  in  the  future/  the  segments  are  given  contiguous 
areas  of  storage.  The  process  remains  flagged  until  it 
either  invokes  a  new  program  with  "exec"  or  terminates. 
APPENDIX  8  contains  more  detail  on  this  subject. 

F.  SUPPORT  PROGRAM  MODIFICATIONS 

During  the  course  of  this  thesis  two  program  development 
tools  were  perfected  and  two  program  errors  in  UNIX  commands 
were  encountered  and  corrected.  These  programs  and 
corrections  have  been  documented  elsewhere  and  are  only 
briefly  discussed  here. 

The  program  development  tools  are:  an  assembly  language 
program  to  dump  memory  onto  the  swap  file  without  operating 
system  support  and  a  C  language  program/  CRASHSAV/  to 
retrieve  the  dump  from  the  swap  file  and  place  it  into  the 
UNIX  file  system.  The  dump  program  was  made  part  of  the 
operating  system.  It  was  executed  from  the  system  control 
panel  following  a  system  failure  to  preserve  the  contents  of 
memory  for  analysis.  This  system  of  taking  and  retrieving 
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complete  memory  dumps  was  extremely  valuable 


PSUN IX  could 


not  have  been  developed  without  it. 

The  two  proqram  errors  were  discovered  in  **nmf**  the 
command  for  printing  symbol  tables  ot  compiled  programs^  and 
in  "sysfixf”  the  command  that  adjusts  the  format  of  a  UNIX 
operating  system  image  so  that  it  can  be  ^’bootstrapped**  into 
memory.  The  errors  were  discovered  because  the  PSUNIX  image 
exceeded  6^K  bytes.  Neither  program  executed  prooerly  with 
the  PSUNIX  image  as  data  because  both  programs  used  counters 
that  overflowed  at  6^K.  The  problem  was  solved  by 
increasing  the  size  of  the  counters. 
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performance  study 


A.  experimental  design 

A  series  of  exoeriments  was  done  to  determine  the 
relative  performance  of  the  UNIX  and  PSUNIX  versions  of  the 
operating  system  under  a  variety  of  operating  conditions. 
The  elapsed  execution  times  of  standard  streams  of  processes 
(benchmarks)  was  chosen  as  the  metric  for  system 
performance.  Two  benchmarks  were  used:  a  monoprogramming 
benchmarks  BENCHl;  and  a  multiproqrammina  benchmarks  BENCH2. 
Both  benchmarks  contained  the  same  processes.  Most 
processes  chosen  for  the  bench m'arks  are  representative  of 
the  I/O  limited  program  development  environment  but  several 
of  them  (notably  a  "Rings  of  Hanoi"  calculation)  are 
processor  limited.  APPENDIX  C  contains  listings  of  the 
commands  in  BENCHl  and  8ENCH2.  Reference  (111  documents 
these  commands. 

The  computer  system  used  to  execute  the  benchmarks  was 
the  "B"  side  of  the  laboratory  configuration  shown  in  Fig. 
1.  The  peripheral  devices  used  were  a  single  terminal  and 
two  1.25  mega-word  RK05  cartridge  direct  access  storage 
devices  (16).  The  file  system  for  the  operating  system  was 
mounted  on  one  of  the  RK05  devices.  To  reduce  I/O 
content ion>  the  other  RK05  device  was  used  for  swapping 


processes  into  and  out  of  main  memory 


The  main  memory 


available  in  the  system  was  the  oarameter  varied  in  the 


experiments. 

B.  presentaiom  of  results 

The  timing  data  presented  in  this  section  was  obtained 
by  executing  the  benchmarks  under  control  of  the  "time” 
command  Cll).  The  times  are  determined  by  sampling  the 
processor  state  at  a  60  hz  rate.  "Real"  time  is  actual 
elapsed  test  time  reoorted  to  the  nearest  second.  "User" 
time  is  the  time  the  processor  spent  executing  instructions 
in  the  User  state.  "Sys"  time  is  the  time  that  the 
processor  spent  executing  instructions  in  the  Kernel  and 
Supervisor  states.  Both  "User"  and  "Sys"  times  are  reported 
to  the  nearest  tenth  of  a  second.  The  difference  between 
"Real"  time  and  the  sum  of  "User"  and  "Sys"  times  is 
processor  idle  time.  Earlier  work  t^]  suggests  that  timings 
of  the  same  benchmark  may  haye  a  standard  deviation  of  as 
much  as  8  percent  of  the  mean  values.  No  statistical  study 
of  these  timings  was  performed  in  the  course  of  this  thesis 
but  limited  observations  indicate  that  the  deviation  is  much 
less  than  8  percent. 

Six  experiments  were  performed.  The  first  was  an 
execution  of  BENCH!/  the  monoprogramming  benchmark/  under 
both  operating  systems.  The  results  of  this  experiment  are 
shown  in  Table  1.  The  next  five  experiments  consisted  of 
executing  8EMCH2  under  both  operating  systems/  varying  the 
amount  of  dynamic  memory  availible  from  32K  words  to  64K 


words  in  8K  word  steps.  The  results  of  these  e^^oeriments 
are  shown  in  Tables  2  to  6  respectively.  Combined  results 
are  shown  in  Fig.  a  graph  of  elapsed  times  against 
dynamic  memory  available. 

C.  ANALYSIS  OF  RESULTS 

The  experimental  results  clearly  indicate  that  the 
performance  of  PSUNIX  and  the  performance  of  UNIX  are  almost 
identical  over  a  wide  range  of  sizes  of  available  dynamic 
memory.  Both  the  amounts  of  processor  idle  time  and  of 
supervisory  overhead  are  approximately  equal  in  all 
corresponding  experiments.  The  approximate  equality  of  idle 
times  indicates  that  the  disadvantage  of  increased  swapping 
overhead  in  PSUNIX  is  offset  by  a  reduction  in  the  number  of 
processes  swapped  because  of  reduced  external  fragmentation. 
The  approximate  eauality  of  the  supervisory  overhead 
indicates  that  the  advantage  of  reduced  segment  copying  in 
PSUNIX  is  offset  by  the  increased  complexity  of  the  memory 
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CONCLUSIONS  AND  RECOMMENDATIONS 


The  most  interesting  result  of  this  thesis  is  that  it 
confirms  the  axiom  that  a  simple  program  is  very  often  a 
good  program.  From  the  standooint  of  performance  alone/  the 
simpler  UNIX  memory  manager  is  as  efficient  as  PSUNIX. 
PSUNiX  is  attractive  because  it  provides  an  additional 
feature/  segmentation/  with  no  performance  penalty. 
Although  PSUNIX  could  be  placed  into  production  use  at  once/ 
it  would  probably  be  a  better  idea  to  proceed  with  the 
development  of  SUNIX.  From  the  data  presented  on  segment 


sizes/  it  appears  that  SUNIX  will 

perform  at  least  as  well 

as  PSUNIX.  SUNIX  memory  management 

routines  will  have  the 

advantages  of  being  both  smaller 

and  simpler.  Because  of 

this/  they  will  reguire  less  storage/  be  easier  to  maintain/ 
and  cause  less  memory  management  overhead. 

No  matter  which  version  is  implemented/  many  parts  of 


the  memory  manager  will  remain 

potential  candidates  for 

improvement#  The  basic  memory 

allocation  primitive/ 

^*malloC/”  is  an  example#  In  ref. 

[61/  Knuth  suggests  many 

possible  improvements  to  the  simple  algorithm  used  in 
"malloc."  Although  Knuth's  logic  is  compelling/  we  may  again 
be  surprised  by  the  correlation  between  simplicity  and 


goodness 


A  more  irnoortant  project  will  be  the  development  of  the 
system  calls  that  will  be  used  to  olace  a  process's  data 
segment  in  specific  areas  of  memory.  Successful  completion 
of  this  oroject  will  be  reauired  before  the  full  benefits  of 
segmentation  will  be  attained. 
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APPENDIX  A:  memory  MANAGEMENT  CONTROL  BLOCKS 


A,  DOCUMENTATION  FORMAT 

This  aopendix  contains  documentation  of  the  control 
blocks  in  the  UNIX,  SUM IX,  and  PSUNIX  versions  of  the 
ooeratinq  system  that  are  direcly  or  indirectly  concerned 
with  memory  management.  The  source  code  for  these  control 
blocks  is  found  in  files  in  the  directory  /usr/sys.  Each 
control  block  is  documented  under  an  uoper  case  roman 
letter.  The  name  of  the  source  code  file  containing  the 
control  block  is  noted  following  the  control  block  name. 
The  documentation  of  each  control  block  is  divided  into  two 
subsections:  overview  and  significant  data  elements.  Only 
the  data  elements  significant  to  memory  management  are 
documented.  Because  this  appendix  was  designed  to  be  used 
with  a  copy  of  the  system  code,  the  data  elements  are 
documented  in  the  order  in  which  they  appear  in  the  source. 

In  accordance  with  the  non-disclosure  terms  of  the 
software  agreement  with  Western  Electric,  program  listings 
are  not  provided  as  Part  of  this  thesis.  Authorized  users 
of  the  UNIX  operating  system  may  obtain  machine-readable 
copies  of  programs  produced  for  this  thesis  by  contacting 
the  Naval  Postgraduate  School. 
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B,  COREMAP/  systm.h 


I  .  Overview 

coremap  is  an  array  of  structures  that  keeps  track 
of  the  unallocated  areas  of  main  storage.  Each  structure 
contains  the  starting  physical  block  number  and  the  size  of 
an  unallocated  storage  area.  COREMAP  is  sorted  so  that  its 
entries  are  in  physical  block  number  seauence.  See  the 
documentation  of  '’malloc.c'*  in  APPENDIX  B  for  descriotions 
of  the  memory  management  primitives  that  manipulate  COREMAP. 

2.  Significant  Data  Elements 

a.  char  *m^-si2e 

This  is  the  size  of  the  free  area  in  6^-byte 

blocks. 


b.  char  ^^m^addr 

This  is  the  memory  physical  block  number  of  the 
start  of  the  free  area.  If  this  field  is  zero ,  it  marks  the 
end  of  COREMAP, 

C.  S;/^iAPMAPf  systm.h 

1.  Overview 

Sl^APMAP  is  an  array  of  structures  that  keeps  track 
of  the  unallocated  areas  on  the  swap  device.  Each  structure 
contains  the  starting  physical  sector  number  and  the  size  of 


an  unallocated  area.  SWAP MAP  is  sorted  so  that  its  entries 
are  in  physical  sector  number  sequence.  The  same  primitives 
used  to  maipulate  COREMAP  are  used  for  SrtAPMAP.  See 
APPENDIX  B. 

2.  Significant  Data  Elements 

a.  char  *m<-si2e 

This  is  the  size  of  the  free  area  in  256-word 

sectors . 

b.  char  *m<-addr 

This  is  the  memory  physical  sector  number  of  the 
Start  of  the  free  area.  If  this  field  is  zero  t  it  marks  the 
end  of  SWAP MAP, 


D.  PR0C»  oroc.h 

1.  Overview 

The  array  "oroc"  is  an  array  of  structures  referred 
to  as  PROCs  in  this  thesis.  One  of  these  structures  is 
allocated  to  each  active  process  in  the  system  for  the  life 
of  the  process.  The  array  is  located  in  the  Kernel  address 
space  ana  is  oermanently  resident  in  main  memory.  A 
process's  PROC  contains  all  orocess  information  that  cannot 
be  swapped  out  of  main  memory. 


50 


2.  Significant  Data  Elements 


a,  char  p*-f1ag 


This  is  a  word  of  flags.  Bit  0  of  this  word  is 
the  SLOAD  flag.  If  it  is  set/  the  process  is  in  main  memory. 
Bit  2  of  this  word  is  the  SLOCK  flag.  If  it  is  set/  the 
process  is  locked  in  memory  and  may  not  be  swapped  out.  Bit 
^  of  this  word  is  the  SSWAP  flag?  if  it  is  set/  the  process 
is  being  swapped  out.  In  PSUNIX/  bit  15  of  this  word  is  the 
CONT  flag.  If  the  bit  is  set/  it  means  that  both  the 
process's  data  and  the  orocess's  stack  must  be  contiguous  in 
ma i n  memo  r y  . 


b.  int  p*-addr 

This  field  is  present  only  in  UNIX.  If  the 
process  is  resident  in  main  memory/  it  is  the  physical  block 
number  of  the  orocess's  UVECTOR.  If  the  process  is  swapped 
out/  it  is  the  swap  device  block  number  of  the  swapped 
i mage . 


c.  int  p<-size 


This  field  is  present  only  in  UNIX.  It  is  the 
size  of  the  orocess's  swaooable  image  measured  in  b^-byte 
blocks. 

d  .  int  *p<-t  ex  t  p 

This  is  a  pointer  to  the  orocess's  TEXT.  If  the 
value  is  zero/  the  process  does  not  have  shared  text. 


51 


e.  int  p<-cadar 

This  field  is  present  only  in  SUMIX  and  PSD NIX. 

It  is  the  main  memory  physical  block  number  of  the  process's 
UVECTOR  if  the  process  is  in  memory.  t 

f  .  int  o«-oador  (8] 

This  array  is  present  only  in  PSUNIX.  The 
integers  in  the  array  are  the  memory  physical  block  numbers 
of  the  process's  pages.  The  order  of  pages  is:  first  data 
pages  from  low  to  high  virtual  address  and  then  stack  pages 
from  high  to  low  virtual  address. 

g.  int  o<-dadar 


This  field 

1  s 

present  only 

1  n 

SUNIX 

and 

PSUNIX  . 

It 

i  s 

the 

swap  device 

block  number 

o  f 

the  process 

' s  swap 

space • 

If  i 

t  is  zero/ 

the 

process  has 

no 

Swap 

space. 

h  . 

i  n  t  p«-ds  i  ze 

This  field 

i  s 

present  only 

i  n 

SUNIX 

and 

PSUNIX  . 

It  is  the  size  of  the  process's  data  in  b^l-byte  blocks. 

i  .  int  o<-ss  i  ze 

This  field  is  present  only  in  SUNIX  and  PSUNIX. 
It  is  the  size  of  the  process's  stack  in  b^-byte  blocks. 
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E.  TEXT/  text.h 

1.  Overview 

The  array  "text"  is  an  array  of  structures  called 
TEXTS  in  this  thesis.  Each  segment  of  sharable  code  is 
assigned  a  TEXT  for  the  life  of  the  segment.  The  text 
contains  all  data  on  the  usage  and  status  of  the  segment. 
The  "text"  array  is  found  in  the  Kernel  address  space  and  is 
permanently  resident  in  main  memory. 

2.  Significant  Data  Elements 

a  .  i  n  t  x«-dadd  r 

This  is  the  swap  device  block  number  of  the  text 
segment's  image. 

b.  int  x<-caddr/  int  xcaddr  [8] 

In  UNIX  and  SUNIX/  this  is  the  memory  physical 
block  number  of  the  start  of  the  text  segment.  In  PSUNIX 
this  array  contains  the  memory  physical  block  numbers  of  the 
cages  of  the  text  segment. 

c  .  int  X «-  s  i  z  e 

This  is  the  size  of  the  text  segment  in  b^-byte 

blocks. 
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d 


char  x<-count 


segment  . 


This  is  the  number  of  processes  sharing  the  text 


e.  char  x<-ccount 

This  is  the  number  of  memory  resident  processes 
using  the  text  segment. 

F.  UVECTORf  user.h 

1.  Overview 

The  structure  "user"  is  referred  to  as  the  UVECTOP 
in  this  thesis.  One  of  these  structures  is  part  of  the 
swappable  image  of  each  orocess.  The  UVECTOR  contains  all 
process  data  that  is  not  needed  wnen  the  process  is  not  in 
control  of  the  processor.  When  the  process  is  in  control  of 
the  processor;  the  orocess's  UVECTOR  resides  at  virtual 
Kernel  data  space  address  140000  octal.  The  oortion  of  the 
UVECTOR  not  used  by  orocess  data  elements  is  used  as  the 
Kernel  mode  processor  stack. 

2.  Significant  Data  Elements 

a.  int  u«-uisatl6] 

In  UNIX  this  array  contains  the  64-byte  block 
displacements  from  the  start  of  the  region  of  the  process's 
data  and  stack  pages.  In  SUN IX  and  PSUNIX  this  array  is  not 


used 


b 


int  u«-uisd[16] 


This  array  contains  the  prototypes  of  the 
process's  user  I-soace  and  D-soace  page  descriptor 
registers. 

c.  int  u«-tsize 

This  is  the  size  of  the  process's  shared  text 

segment . 

d  .  int  u<-ds  i  z  e 


This  is  the  size  of  the  process's  data. 

e.  int  u+-ssize 


This  is  the  size  of  the  process's  stack. 


G .  PAGET ,  oage  .  h 

1.  Oyeryiew 

An  array  of  "paget"  structures  is  referred  to  as  a 
PAGET  in  this  thesis.  This  is  a  page  table  containing  the 
sizes  and  addresses  of  the  process's  pages.  A  PAGET  is 
always  organized  so  that  data  pages  apoear  first  from  low  to 
high  yirtual  address  followed  by  stack  pages  from  high  to 
low  virtual  address. 
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2.  Significant  Data  Elements 

a  .  i  n  t  t  <-oadd  r 

This  is  the  memory  physical  block  number  of  the 
start  of  the  page. 

b  .  i  n  t  t  <-DS  i  ze 

This  is  the  size  of  the  cage  in  b^l-byte  blocks. 
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APPENDIX  B;  MEMORY  MANAGEMENT  ROUTINES 


A.  documentation  format 


This  aopendix  contains  documentation  of  functions  within 
the  UNIX/  SUNIX/  and  PSUNIX  versions  of  the  operating  system 
that  are  directly  or  indirectly  concerned  with  memory 
management.  Because  this  aopendix  is  designed  to  be  used 
with  a  copy  of  the  source  code/  the  documentation  is  divided 
into  sections  that  correspond  to  the  divisions  of  the  source 
code.  The  UNIX  source  is  divided  into  several  blocks  of 
code  containing  related  functions.  These  blocks  of  code  are 
stored  as  files  in  two  directories:  /usr/sys/dmr  for  device 
management  functions  and  /usr/sys/ken  for  the  remainder  of 
the  system.  The  documented  functions  in  each  block  of  code 
are  grouped  under  an  upper  case  roman  letter.  Each  function 
within  each  block  is  listed  under  an  arabic  numper.  The 
functions  are  documented  in  the  same  order  in  which  they  are 
found  in  the  code  blocks  with  any  new  functions  aopearing 
last.  The  documentation  of  each  function  is  divided  into 
the  following  subsections:  parameters/  functional 
description/  returned  values/  and  error  conditions.  Any 
differences  in  function  documentation  among  the  three 
versions  of  the  operating  system  are  noted  in  the 
appropriate  subsection. 
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B .  ma i n  .  c 

1 .  sureg ( ) 

a.  Parameters 

The  current  process's  UVECTOR  and  PROC  are 

implied  parameters. 

b.  Functional  Description 

This  function  loads  the  User  descriptor  and 
address  registers  in  the  memory  management  unit.  The 
descriptor  registers  are  obtained  from  the  array  u<-uisdC]  in 
the  current  UVECTOR.  Address  register  loading  is  controlled 
by  the  values  of  u<-tsi2e»  u^-dsize/  u<-ssi2e»  and  u^-sep  in 

the  current  UVECTOR,  In  UNIX  the  page  address  registers  are 
determined  based  on:  the  region  address/  o<-addr/  in  the 
current  PROC;  the  text  segment  address/  x<-caddr/  in  the 
current  TEXT;  and  the  page  displacements  in  the  array 
u<-ui3aC]  in  the  current  UVECTOR,  The  page  displacements  are 
not  used  in  SUNIX  or  UNIX.  In  SUNIX  the  segment  adoresses/ 
o<-daddr  and  o<-saddr/  are  used  instead  of  p<-addr.  In  PSUNIX 

the  page  addresses  in  the  array  p<-paddr[]  in  the  PROC  and 

x<-caddrl]  in  the  TEXT  are  used. 

c.  Returned  Values 

The  values  returned  by  this  function  are  not 

checked. 
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d.  Error  Conditions 


This  function  has  no  error  conditions, 

2.  es t abu r ( n t » nd / ns » sen ) 

a.  Parameters 

The  first  three  parameters  are  the  sizes  of  the 
current  process's  data  and  stack  in  b^-byte  blocks.  The 
value  of  "seo"  is  a  flag  that  is  set  if  the  process  has 
split  instruction  and  data  space.  The  current  process's 
UVECTOR  is  an  implied  input. 

b.  Functional  Description 

This  function  first  checks  the  validity  of  its 
arguments.  It  loads  the  prototypes  of  the  memory  management 
page  descriptor  registers  into  the  array  u<-uisd[]  in  the 
current  UVECTOR.  In  UNIX  it  also  loads  page  start 
displacements  in  blocks  measured  from  the  beginning  of  the 
region  or  text  into  the  array  u<-uisal]  in  the  current 
UVECTOR,  In  both  SUNIX  and  PSUNIX/  u«-uisa[]  is  not  loaded; 
the  values  of  the  parameters  are  placed  in  the  variables 
u<-tsize»  u<-dsize/  u^-ssize^  and  u*-sep  in  the  current  UVECTOR. 
In  all  versions/  "sureg()"  is  called  to  load  the  actual 
memory  management  registers. 

c.  Returned  Values 

If  the  parameters  are  invalid/  minus  one  is 
returned;  otherwise/  zero  is  returned. 
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d.  Error  conditions 


The  minus  one  return  indicates  an  error  to  the 

cal  1 e  r  . 

3 .  nseg ( n ) 

a .  Paramet  ers 

The  oarameter  is  a  number  of  memory  blocks. 

b.  Functional  Description 

This  function  calculates  the  number  of  Dages» 
rounded  ud^  in  the  number  of  blocks  specified  in  the 
parameter. 

c.  Returned  Values 

The  returned  value  is  the  number  calculated. 

d.  Error  Conditions 

This  function  has  no  error  conditions. 

y.  c ks i ze ( n t / nd f n s / sep ) 

a .  Paramet  ers 

See  "estabur(nt/nd/ns/sep).'' 

b.  Functional  Description 

This  function  is  present  only  in  SUNIX  and 
PSUNIX.  It  checks  its  parameters  to  see  if  they  are  valid. 
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c.  Returned  Values 


This  function  returns  minus  one  if  the 
parameters  are  invalid  and  zero  if  they  are  valid. 

d.  Error  Conditions 

A  minus  one  return  indicates  an  error  to  the 

cal  1 er . 

C .  ma 1  1 oc  .  c 

1,  malloc(mD/size) 

a .  Paramet  ers 

The  parameters  are  a  pointer  to  a  mao  array  and 
a  size  specified  in  blocks  to  be  allocated  from  the  mao. 

b.  Functional  Description 

This  function  allocates  space  in  main  memory  and 
on  the  swap  device.  If  memory  is  to  be  allocated/  the  first 
parameter  must  point  to  COREMAP.  If  swap  soace  is  to  be 
allocated/  it  must  point  to  SWAPMAP.  The  amount  of  soace 
needed  must  be  specified  in  6il-byte  blocks  if  memory  is  to 
be  allocated  and  in  256-word  sectors  if  swap  space  is  to  be 
a  1  located. 

c.  Returned  Values 

This  function  returns  the  physical  block  number 
of  the  soace  if  allocation  is  successful  and  zero  if 
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allocation  is  unsuccessful. 

d.  Error  Conaitions 

A  return  value  of  zero  indicates  allocation 
failure  to  the  caller. 

2.  m f ree ( mp , s 1 ze » aa ) 

a .  Pa  r ame  t  e  r s  ' 

The  first  two  oarameters  are  the  same  as  those 
of  "malloc".  The  third  parameter  is  a  physical  block  number 
of  an  area  of  main  storage  or  swap  soace. 

b.  Functional  Description 


This  function  frees  the  specified  area  of  main 


storage  or  swap  soace. 

I  f  m  e'Tio  r  y  is 

to  be 

f  r eed  f 

the  first 

parameter 

must  point  to 

COREMAP 

.  If 

swap 

space  1 

s  to  be 

f  r eed »  it 

must  point  to 

SwAPMAP 

.  The 

size 

must  be 

spec i f i ed 

in  6^-byte 

blocks  if  memory  is 

to  be 

freed 

and  i  n 

256-word 

sectors  i f 

swap  space  i 

s  to  be 

freed. 

c  • 

Ret  urned  Val ues 

The  value 

returned 

by 

this 

f unc  t ion 

is  not 

checked. 


d.  Error  Conaitions 


This  function  has  no  error  conditions. 
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D 


s  1  g  .  c 


I  .  CO  re  ( ) 

a.  Parameters 

The  current  process's  UVECTOR,  PROC/  TEXT  and 
address  space  are  implied  parameters. 

b.  Functional  Description 

This  function  creates  a  memory  image  file 
consisting  of  the  current  process's  UVECTOR^  data^  and 
stack.  In  UNIX  this  function  uses  '’estabur"  to  redefine  the 
process's  virtual  address  space  to  make  the  data  and  stack 
contiguous.  It  then  writes  the  data  and  stack  in  one  output 
operation.  In  SUNIX  and  PSUNIX  this  is  impossible  because 
the  data  and  stack  may  not  be  physically  contiguous.  Two 
output  operations  are  used/  one  output  operation  for’  the 
data  and  one  for  the  stack.  If  an  output  error  occurs  an 
indication  is  left  in  u^error  in  the  current  UVECTOR. 

c.  Returned  Values 

This  function  returns  zero  if  it  is  successful 
and  one  if  an  output  error  occurs. 

d.  Error  Conditions 

The  one  return  indicates  an  error  to  the  caller. 
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2  .  g  row ( sp ) 


a.  Parameters 

\ 

The  parameter  is  the  value  of  the  current 
process's  User  stack  pointer.  The  current  process's  UVECTOR 
and  PROC  are  implied  parameters. 

b.  Functional  Description 

This  function  is  called  asynchronously  when  the 
current  process's  stack  attempts  to  expand  beyond  the  size 
allocated  to  it.  This  function  calculates  the  number  of 
blocks  that  the  stack  must  be  increased^  validates  the  new 
stack  sizef  and  acquires  the  memory  that  is  needed.  In  UNIX 
"expand"  is  called  to  establish  the  newf  larger  address 
space.  In  PSUNIX  "sexpand"  is  called  to  establish  the  new^ 
larger  stack.  In  SUNIX  this  function  attempts  to  acquire 
space  for  the  new  stack.  If  it  is  unsuccessfulf  it  calls 
"ceswao"  to  acquire  the  space.  If  it  is  successful/  it 
copies  the  old  stack  to  the  new  and  frees  the  old  memory. 
In  all  versions  the  newly  acouired  space  is  cleared  and 
"estabur"  is  called  to  reload  the  memory  management 
regi sters. 

c.  Returned  Values 

This  functon  returns  a  zero  if  it  is 

unsuccessful  and  a  one  if  it  is  successful. 
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d.  Error  Conditions 


A  zero  return  indicates  an  error  to  the  caller. 


E  .  s  1  o  .  c 

1 .  sc  hed ( ) 

a.  Parameters 

The  PROCs  and  TEXTs  of  all  processes  are  implied 

parameters . 

b.  Functional  Description 

This  function  searches  for  swapped  out  processes 
that  "deserve"  to  be  returned  to  memory.  It  selects  the 
most  "deserving"  process?  acquires  space  for  it  by  swapping 
out  other  orocessesf  if  necessary?  and  returns  it  to  main 
memory.  In  SUM IX  and  PSUNIX  two  new  functions  are  used? 
"pralloc"  to  acquire  main  memory  for  the  process  and 
"prswap"  to  swap  it  in. 

c.  Returned  Values 

This  function  does  not  return.  It  is  the  basic 
instruction  looo  of  Process  0.  It  goes  to  sleep  and  is 
reawakened  about  once  oer  second  by  the  clock  function. 

d.  Error  Conditions 

In  UNIX/  if  a  swap  input  or  output  error  occurs/ 
the  message  "swap  error"  will  be  sent  to  the  console  and  the 
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system  will  crash 


2.  newproc(nrD) 

a.  Parameters 

The  oarameter  is  a  pointer  to  a  PROC  to  be 
established  for  a  child  process.  The  current  process's 
UVECTOR,  PROCf  and  TEXT  are  implied  parameters. 

b»  Functional  Description 

This  function  creates  an  exact  duplicate  of  the 
current  process  as  a  child  of  the  current  process.  It  first 
makes  the  appropriate  entries  in  the  child  and  parent  PROCs 
and  in  the  TEXT  if  one  exists.  It  then  attempts  to  acquire 
memory  for  the  child.  If  it  is  successful/  it  simoly  copies 
the  parent's  image  to  the  new  memory.  If  it  fails/  it  swaps 
out  a  copy  of  the  oarent's  image  to  be  returned  to  memory  as 
the  child.  In  SUNIX  and  PSUNIX/  a  new  function/  "pralloc/" 
is  used  in  the  attemot  to  acquire  memory  for  the  child.  In 
PSUNIX  a  new  function  "prcooy"  is  used  to  cooy  the  Parent's 
image. 


c.  Returned  Values 

This  function  returns  zero  to  the  oarent 
process.  The  return  to  the  child  does  not  come  from  this 
function  but  from  the  scheduling  function  "swtch".  The 
child  can  identify  itself  as  the  child  because  "swtch" 
returns  a  one  to  it.  This  is  one  of  the  most  imoortant  and 
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subtle  phenomena  in  UNIX. 


d.  Error  Conditions 

If  the  PROC  pointed  to  by  the  parameter  is 


a  1  ready  a  1  located 

t  0 

an 

active  orocess 

,  the  message 

procs"  will  be  sent 

t  0 

the 

console  and 

the  system 

crash. 

3.  exoand ( news i ze ) >  expandCnewd^  news) 

a.  Parameters 

In  UNIX  this  function  is  called  with  a  single 
parameter^  the  new  region  size.  In  SUNIX  and  PSUNIX  this 
function  is  called  with  two  parameters:  the  new  data  size 
and  the  new  stack  size.  The  current  process's  PROC  and 
UVECTOR  are  implied  Parameters. 

b.  Functional  Description 

In  UNIX  this  function  is  called  whenever  the 

size  of  the  current  orocess's  address  space  changes.  It  outs 
the  new  size  in  o*-size  in  the  current  PROC.  If  the  new  size 

is  smaller,  it  frees  the  unwanted  storage.  If  the  new  size 

is  larger,  it  attempts  to  acquire  a  new  region  for  the 

process.  If  it  succeeds,  it  copies  the  process's  image  to 
the  new  region.  If  it  fails,  it  causes  the  process  to  be 
swapped  out  with  the  new  size  noted  in  its  PROC.  When  the 
process  returns  to  memory,  it  will  return  at  the  new  size. 
If  the  process  is  swapped  out,  this  function  calls  "swtch" 


to  change  current  processes.  In  SUNIX  and  PSUNIX,  this 
function  is  called  only  to  acquire  an  address  space  for  a 
process  that  currently  has  only  a  UVECTOR.  In  these  systems 
it  outs  the  two  new  sizes  in  o<-dsize  and  p«-ssize  in  the 
current  PROC.  In  UNIX  the  function  "xswap"  is  called  to 
swap  out  the  process#  in  SUNIX  and  PSUNIX  "ceswap"  is  used. 
In  UNIX#  "sureq"  is  called  to  load  memory  management 
registers#  in  SUNIX  and  PSUNIX#  this  is  not  necessary. 

c.  Returned  Values 

The  return  codes  of  this  function  are  not 
checked.  The  caller  has  no  way  of  determining  if  the  process 
was  increased  in  size  directly  or  by  swapping.  In  UNIX#  if 
the  process  is  swappeo#  this  function  does  not  return  to  its 
caller.  The  return  comes  from  a  subsequent  call  to  "swtch" 
after  the  process  has  returned  to  memory. 

d.  Error  Conaitions 

This  function  has  no  error  conditions. 

4.  ceswap ( ods # OSS ) 

a.  Parameters 

The  parameters  are  the  current  process's  data 
and  stack  sizes  in  b^-byte  blocks. 
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b.  Functional  Oescriotion 


This  function  is  present  only  in  SUNIX  and 
PSUNIX.  It  is  called  to  do  the  housekeeping  that  is 
necessary  for  expansion  swapping.  It  calls  "xswao'*  to 
perform  the  actual  swapoing  and  then  it  calls  "swtch”  to 
place  a  new  process  in  control  of  the  processor. 

c.  Returned  Values 

This  function  does  not  return  to  its  caller. 
The  return  to  the  caller  comes  from  a  subseauent  call  to 
"swtch"  after  the  process  has  returned  to  memory. 

d.  Error  Conditions 

This  function  has  no  error  conditions. 

5  .  s w  f  ree ( rp 1 

a.  Parameters 

The  oarameter  is  a  pointer  to  a  PROC. 

b.  Functional  Oescriotion 

This  function  frees  any  swap  soace  belonging  to 
the  process  indicated  by  the  oarameter,  and  it  zeroes  out 
p^-daddr,  the  pointer  to  the  soace  in  the  PROC. 

c.  Returned  Values 

* 

The  values  returned  by  this  function  are  not 


checked 


d.  Error  Conditions 


This  function  has  no  error  conditions. 

6*  sexoand (news ) 

Parameters 

The  parameter  is  the  new#  larger  stack  size. 

b.  Functional  Descriotion 

This  function  is  present  only  in  PSUNIX,  It  is 
called  from  "grow"  to  increase  the  stack  size.  See  the 
description  of  "exoand". 

c.  Returned  Values 

See  "expand". 

d.  Error  Conditions 

See  "expand". 

7,  dexpand ( newd ) 

a.  Parameters 

The  oarameter  is  the  new/  larger  data  size. 

b.  Functional  Descriotion 

This  function  is  present  only  in  PSUNIX.  It  is 
called  from  "sbreak"  to  increase  the  data  size.  See  the 
descriotion  of  "expand". 


J 
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c.  Returned  Values 

See  "expand". 

d.  Error  Conoitions 

See  "expand". 

8.  contigCro) 

a.  Parameters 

The  parameter  is  a  pointer  to  the  current 
process ' s  PROC . 

b.  Functional  Description 

This  function  is  present  only  in  PS UNIX.  It  is 
called  from  "physio"  to  make  both  the  stack  and  the  data  of 
the  current  process  physically  contiguous  in  main  storage. 
It  indicates  that  the  process  requires  contiguous  segments 
by  setting  the  CONT  bit  in  the  p<-flag  in  the  process's  PROC; 
then  it  attempts  to  acquire  physically  contiguous  main 
storage  with  "oalloc".  If  it  succeeds^  it  copies  the  old 
noncontiguous  pages  to  the  new  contiguous  ones.  If  it 
fails/  it  calls  "ceswap"  to  swap  out  the  process.  When  it 
returns  to  main  memory/  the  CONT  flag  will  cause  its  storage 
to  be  allocated  contiguously. 

c.  Returned  Values 

The  values  returned  by  this  function  are  not 


checked 


d .  Error  Conditions 


This  function  has  no  error  conditions. 


F .  sy s  1  .  c 

1 .  exec  ( ) 


a .  Paramet  ers 


The  current  process's  UVECTORf  PR0C»  ana  TEXT 
are  implied  parameters.  Because  this  function  is  a  system 
calif  the  array  u<-argC]  in  the  UVECTOR  contains  additional 
arguments.  See  Ref.  [111. 


b.  Functional  Description 

This  system  call  is  used  by  the  current  process 
to  invoke  a  new  program.  It  copies  any  program  arguments  to 
a  bufferf  unlinks  from  the  old  TEXTf  frees  its  old  main 
storage/  establishes  a  new  TEXT  if  the  new  program  has 
shared  code/  acquires  storage  for  the  new  data  and  stack/ 
clears  the  region  acquired/  reads  in  the  new  data/  copies 
the  arguments  to  the  new  stack/  and  changes  the  memory 
management  registers  to  make  them  compatible  with  the  new 
address  space.  In  UNIX  "expand"  is  used  to  free  the  old 
main  storage;  in  SUNIX  and  PSUNIX  a  new  function/  "prfree"/ 
is  used.  In  UNIX  "estabur"  is  used  to  validate  the  storage 
requirements  of  the  new  program;  in  SUNIX  and  PSUNIX 
"cksize"  is  used. 
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c.  Returned  Values 


This  system  call  returns  to  the  caller  only  if 
it  encounters  an  error.  If  no  error  has  occurred/  it 
returns  to  the  first  instruction  of  the  new  program. 

d.  Error  Conditions 

This  function  returns  to  the  caller  if  the 
storage  requirements  of  the  new  orogram  are  invalid. 

2 .  ex i t  ( ) 

a .  Parameters 

The  current  process's  UVECTOR/  PROC/  and  TEXT 
are  imolied  parameters. 

b.  Functional  Description 

This  function  is  the  system  call  used  to 
terminate  the  current  process.  It  clears  signals/  closes 
any  open  files/  unlinks  from  the  current  TEXT/  acquires  a 
block  on  the  swap  device/  copies  the  first  25b  bytes  of  the 
current  UVECTOR  to  the  block/  and  frees  main  storage.  In 
SUN IX  and  PSUNIX/  old  main  storage  is  freed  by  "prfree/"  a 
new  function.  Because  of  the  different  method  of 
controlling  swap  space/  SUNIX  and  PSUNIX  use  "swfree"  to 
free  any  swao  space  allocated  to  the  process. 
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c.  Returned  Values 

This  system  call  does  not  return  to  its  caller. 
The  next  function  invoked  for  this  process  is  "wait'*  which 
completes  the  cleanup. 

d.  Error  conditions 

This  system  call  has  no  error  conditions. 

3  .  sb  r eak ( ) 

a .  Pa  r ame  t  e  r  s 

The  current  process's  UVECTOR  and  PROC  are 
implied  parameters.  Because  this  function  is  a  system  calW 
an  additional  arguments  the  virtual  address  of  the  new  end 
of  the  data^  is  found  in  the  array  u^argC)  in  the  UVECTOR, 

b.  Functional  Description 

This  function  is  the  system  call  used  to  change 
the  size  of  the  current  process's  data  area.  It  calculates 
the  new  data  size  desired  by  the  current  process  and 
validity  checks  the  current  process's  total  storage 
requirement.  If  the  requirement  is  not  valid  it  returns 
without  fulfilling  the  requirement.  In  UNIX,  "expand"  is 
used  to  establish  the  new  region.  In  PSUNIX»  "dexpand"  is 
used  to  change  the  size  of  the  data.  In  SUNIX#  this 
function  attempts  to  do  the  work  itself.  It  puts  the  new 
size  in  p«-dsize  in  the  current  PROC,  If  the  new  size  is 
smaller#  it  frees  the  excess  storage.  If  the  new  size  is 
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largerf  it  attempts  to  acauire  it.  If  it  fails^  it  calls 
"ceswap"  to  acauire  the  space  by  swapping.  In  all  systems 
the  newly  acquired  space  is  cleared. 

c.  Returned  Values 

Values  returned  by  this  system  call  are  not 

checked. 


d.  Error  Conoitions 

If  the  new  storage  requirement  is  not  validf 
this  system  call  returns  without  allocating  the  storage. 
This  will  usually  cause  the  process  to  terminate  abnormally 
because  of  a  memory  management  error. 

G.text.c 

1,  X  swap ( 0 > f f f os ) /  X s wap ( p » f f f ods > os s ) 

a.  Parameters 

In  UNIX  this  function  is  called  with  three 
parameters.  In  SUNIX  and  PSUNIX/  it  is  called  with  four 
parameters.  The  first  parameter  is  a  pointer  to  the  PROC  of 
a  process  to  be  swapped  out  of  main  memory.  The  second 
parameter  is  the  memory  free  flag.  In  UNIX  the  third 
parameter  is  the  process's  region  size  in  6^*byte  blocks. 
In  SUNIX  and  PSUNIX  the  third  and  fourth  parameters  are  the 
process's  data  and  stack  sizes  in  6i(-byte  blocks. 
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b.  Functional  Descriotion 


In  UNIX  this  function  allocates  swao  soace  for 
the  process  and  swaos  it  out.  In  SUNIX  and  PSUNIX  this 
function  allocates  swao  space  only  for  those  processes  that 
do  not  already  have  it.  In  all  versions  of  the  operating 
system#  memory  is  freed  if  the  memory  free  flag  is  set. 

This  flag  will  not  be  set  if  this  function  has  been  called 
by  "newproc”  to  create  a  copy  of  a  oarent  orocess, 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

chec  ked , 

d.  Error  Conditions 

If  swao  space  must  be  allocated  but  none  is 

available#  the  message  "out  of  swao  space"  will  be  sent  to 
the  console  and  the  system  will  crash.  If  an  outout  error 

occurs  during  the  swao#  the  message  "swao  error"  will  be 

sent  to  the  console  and  the  system  will  crash. 

2 .  X  f  ree ( ) 

a.  Parameters 

The  current  process's  UVECTOR  and  TEXT  are 


implied  oarameters 


b.  Functional  Descriotion 


This  function  relinquishes  use  of  the  current 
process's  shared  text.  If  the  current  process  has  no  shared 
text/  this  function  just  returns.  If  the  current  process 
has  shared  text/  "xccdec"  is  called  to  decrement  the  TEXT’S 
in-memory  use  count.  The  TEXT'S  active-process  use  count  is 
then  decremented.  If  this  count  has  reached  zero  and  if  the 
text  segment  is  not  to  be  retained/  the  TEXT'S  swap  space 
and  the  TEXT  itself  are  freed. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked. 


d.  Error  Conditions 

This  function  has  no  error  conditions. 

3 .  xa 1 1 oc ( i P ) 

a.  Parameters 

The  parameter  is  a  pointer  to  the  inode  of  the 
text  segment  that  is  to  be  established  or  located.  The 
current  process's  UVECTOR  and  PROC  and  all  TEXTs  are  imolied 
parameters. 

b.  Functional  Description 

This  function  establishes  the  shared  text 
segment  requested  by  the  current  process.  If  the  current 
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process  does  not  require  shared  text/  this  function  returns. 
If  the  process  does  require  shared  text/  this  function 
searches  the  array  of  TEXTs  for  a  previously  established 
TEXT  for  the  requested  segment.  If  one  is  found  its 
active-process  use  count  is  incremented.  If  the  requested 
segment  is  in  main  memory/  the  TEXT’S  in-memory  use  count  is 
also  incremented  and  the  function  returns.  If  a  TEXT  has 
not  been  previous'ly  established/  an  unallocated  TEXT  is 
located  and  allocated  to  the  text  segment.  Swap  space  is 
allocated  for  the  text  segment.  The  current  process's 
address  space  is  increased  using  "expand"  to  get  soace  into 
which  the  text  segment  can  be  read.  The  text  segment  is 
read  into  memory  and  then  it  is  written  out  to  the  swap 
space  acquired  for  it.  The  memory  acquired  for  the  text 
read  is  freed  using  "expand"  in  UNIX  and  "prfree"  in  SUNIX 
and  PSUNIX,  The  address  of  the  TEXT  is  placed  in  p«*textp  in 
the  current  PROC.  The  current  process  is  swapped  out  with 
"xswap",  When  it  returns  to  memory/  the  text  segment  will 
return  with  it, 

c.  Returned  Values 


c  hec  Iced . 


The  value  returned  by  this  function  is  not 


d.  Error  Conditions 


If  a  TEXT  must  be  allocated  and  one  is  not 
available/  the  message  "out  of  text"  will  be  sent  to  the 
console  and  the  system  will  crash.  If  swao  soace  must  be 
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allocated  and  none  is  available/  the  message  "out  of  swap 
space"  irtill  be  sent  to  the  console  and  the  system  will 
crash  . 

^  .  xccdec ( xo ) 

a .  Paramet  ers 

The  parameter  is  a  pointer  to  a  PROC .  The  PROC ' s  TEXT  is  an 
implied  argument. 

b.  Functional  Description 

If  the  PROC  has  no  TEXT  this  function  returns. 
If  it  has  a  TEXT/  the  TEXT'S  in-memory  use  Count  is 
decremented.  If  the  count  reaches  zero/  the  memory  occupied 
by  the  TEXT'S  text  segment  is  freed. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked. 

d.  Error  Conditions 

This  function  has  no  error  conditions. 


H.  page.c 

1.  pt bu i 1 d ( t ab / s i ze I / s i ze2 / ad ) 
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a.  Parameters 


The  first  parameter  is  a  pointer  to  a  PAGET. 
The  next  two  parameters  are  the  sizes  in  b^-byte  blocks  of  a 
process's  data  and  stack.  The  last  parameter  is  a  pointer 
to  an  array  containing  the  memory  physical  block  numbers  of 
a  process’s  pages. 

b.  Functional  Description 

This  function  is  present  only  in  PSUMIX.  It 
puts  the  sizes  and  addresses  of  a  process's  pages  into  the 
PAGET.  The  order  within  the  PAGET  is  data  pages  first  from 
low  to  high  virtual  address  followed  by  stack  pages  from 
high  to  low  virtual  address.  Unused  PAGET  entries  are 
zeroed . 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked. 


d.  Error  Conditions 

This  function  has  no  error  conditions. 

2.  pt s i ze ( t ab / s i ze I f s i ze2 ) 

a.  Parameters 

The  first  parameter  is  a  pointer  to  a  PAGET. 
The  last  two  parameters  are  the  sizes  in  6^-byte  blocks  of  a 
process's  data  and  stack. 
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b.  Functional  Oescriotion 


This  function  is  present  only  in  PSUNIX.  It 
puts  page  sizes  into  the  PAGET.  The  order  of  sizes  within 
the  PAGET  is  data  pages  from  low  to  high  virtual  address 
followed  by  stack  pages  from  high  to  low  virtual  address. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked. 


d.  Error  Conditions 

This  function  has  no  error  conditions. 


3.  pal  1 oc (ptab/dSf ss/cont ) 


a.  Parameters 

The  first  Parameter  is  a  pointer  to  a  PAGET. 
The  next  two  parameters  are  a  process's  data  segment  and 
stack  segment  sizes  in  b^-byte  blocks.  The  last  parameter 
is  the  contiguity  flag. 


b.  Functional  Description 


This  function  is  present  only 
calls  "ptsize"  to  cut  the  page  sizes 
allocates  main  memory  for  each  PAGET  page 
sizCf  and  puts  the  starting  block  numbers 
memory  into  the  PAGET.  If  allocation  fails 
all  memory  allocated  for  the  process 


in  PSUNIX.  It 
into  the  PAGETf 
with  a  nonzero 
of  the  allocated 
for  any  oage^ 
s  f  reed .  If  the 
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contiguity  flag  is  set>  contiguous  memory  is  allocated  for 


both  the  data  and  stack  cages. 

c.  Returned  Values 

If  allocation  for  all  pages  is  successful^  minus 
one  is  returned.  If  allocation  fails  for  any  page/  zero  is 
returned. 


d.  Error  Conditions 

A  returned  value  of  zero  indicates  an  allocation 
error  to  the  caller. 

pfree(tab) 

a.  Parameters 

The  parameter  is  a  pointer  to  a  PAGET. 

b.  Functional  Description 

This  function  is  found  only  is  PSUNIX.  It  frees 
the  memory  allocated  to  the  cages  in  the  PAGET. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked . 


d.  Error  Conditions 


This  function  has  no  error  conditions. 
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pcopv(otab»ntab) 


a.  Parameters 

The  first  parameter  is  a  pointer  to  the  origin 
PAGET.  The  second  parameter  is  a  pointer  to  the  destination 
PAGET. 

b.  Functional  Description 

This  function  is  present  only  in  PSUNIX.  It 
copies  pages  pointed  to  by  the  origin  PAGET  to  corresponding 
pages  pointed  to  by  the  destination  PAGET.  A  zero  page 
block  number  in  either  PAGET  terminates  the  copying.  The 
number  of  blocks  copied  per  page  is  oetermined  by  the  size 
of  the  origin  page. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked. 


d.  Error  Conoitions 

This  function  has  no  error  conditions. 

6 .  p  ra 1  1 oc ( pr ) 

a .  Pa  r ame  t  e  r s 

The  parameter  is  a  pointer  to  a  PROC.  The 
PROC ' s  TEXT  is  an  implied  input. 
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b.  Functional  Oescriotion 


This  function  is  present  only  in  SUNJX  and 
PSUNIX.  It  acquires  memory  for  the  process's  UVECTOR,  data 
segment,  stack  segment,  and,  if  necessary,  shared  text 
segment.  Space  for  the  text  segment  is  acquired  only  if  the 
text  is  not  main  memory  resident.  If  any  allocation  fails, 
all  memory  previously  allocated  is  freed. 

c.  Returned  Values 

If  all  allocations  are  successful,  the  memory 
block  number  of  the  first  block  allocated  for  the  UVECTOR  is 
returned.  If  any  allocation  fails,  zero  is  returned. 

d.  Error  Conoitions 

A  return  value  of  zero  indicates  an  error  to  the 

cal  1 er . 

7.  pswao ( daddr , t ab , num , f 1 ag ) 

a.  Parameters 

The  first  parameter  is  a  block  number  on  the 
swap  device.  The  second  parameter  is  a  pointer  to  a  PAGET. 
The  third  parameter  is  the  number  of  cages  to  swap.  The 
last  parameter  is  the  read-write  flag. 

b.  Functional  Description 

This  function  is  present  only  in  PSUNiX.  It 
swaps  the  indicated  number  of  pages  to  or  from  main  memory. 
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If  the  read-write  flag  is  set,  the  pages  are  swapped  into 
the  memory  locations  specified  by  the  PAGET,  If  it  is  not 
setf  the  pages  are  swapped  to  the  swap  device  beginning  at 
the  specified  block  number. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked. 


d.  Error  Conaitions 

This  function  has  no  error  conditions. 

8.  orswap(ro) 

a.  Parameters 

The  parameter  is  a  pointer  to  a  PPOC.  The 
PROC's  TEXT  is  an  imolied  incut. 

b.  Functional  Descriotion 

This  function  is  present  only  in  SUNIX  and 
PSUNIX.  It  swacs  a  process's  UVECTOR^  data  segments  stack 
segment/  and/  if  necessary/  text  segment  into  main  memory. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 

checked . 
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Error  Conoitions 


If  an  input  error 

occurs 

during 

the 

s wap  f 

the 

message  "swap  error”  will 

be 

sent 

to  the 

consol e  and 

the 

system  will 

crash. 

I .  b  i  o  .  c 

1.  physioCstrat/  abp/  dev/ 

rw  ) 

a  • 

Pa  rame  t  e  r s 

The  first  parameter 

i  s  a 

Dointer  to 

the 

I/O 

initiation 

rout i ne  rout i ne 

for 

the 

device 

to  be 

used . 

The 

second  parameter  is  to  a  buffer  header  that  contains  control 
information  about  the  I/O  operation  to  be  performed.  The 
third  parameter  is  the  device  identifier.  The  fourth 
parameter  is  a  read/write  flag. 

b.  Functional  Description 

This  function  computes  and  validates  the 
physical  address  of  an  I/O  area  within  the  User  address 
space.  If  the  address  is  valid/  this  function  calls  the  I/O 
initiation  routine  to  start  the  I/O  operation.  In  PSUNIX/ 
this  function  determines  if  the  I/O  area  crosses  a  page 
boundary.  If  it  does  cross  a  boundary/  this  function  calls 
"contiq()'*  to  make  the  reauesting  process  contiguous. 
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c.  Returned  Values 

The  values  returned  by  this  function  are  not 

checked. 

d.  Error  Conditions 


If 

an 

I/O  error 

occurs 

or  the  requested 

ope  r a  t i on 

i  s 

no  t 

valid/  an 

error  condition  is  signaled  by 

setting  a 

b  i  t 

i  n 

u^ue  r  r o  r 

in  the 

requesting  process’s 

UVECTOR. 
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APPENDIX  C:  SYSTEM  BENCHMARKS 


A.  0ENCH1 

chdir  /usr/emery 
sh  old 
chdir  ken 
cc  ”0  -c  s 1 D  .c 

cd  .  . 

cd  dm r 

ed  ipc.c  </us r /bene h /edcmd  >/dev/nu11 

chdir  /usr/bench 

cc  -0  rftest.c 

bas  tower<towerin>/dev/nul 1 

od  /us r /sys/con f /m^S  .  s  >/dev/nul1 

CD  /unix  /dev/null 

chdir  /bin 

sum  *>/dev/nu 1 1 

wait 

chdir  /us r /erne ry / ken 
rm  s 1 p  .  o 

chdir  /usr/bench 
rm  a. out 


8.  8ENCH2 

chdir  /usr/emery 
sh  o 1 d& 
chdir  ken 
cc  -0  -c  si P.C& 

cd  .  . 

cd  dm r 

ed  ipc«c  </us  r /bench/edemd  >/dev/null8. 

chdir  /usr/bench 

cc  ”0  r f  test  .c& 

bas  tower<tower i n>/dev/nu 1 1  & 

od  /us r / sy s/con f /m^5 . s  >/dev/null& 

cp  /unix  /dev/null& 

chdir  /bin 

sum  *>/dev/nul1& 

wait 

chdir  /u s r /eme r y / k en 
rm  s 1 p  .  o 

chdir  /usr/bench 
rm  a«out 
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